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Session Initiation Protocol Signalling 

Field of the Invention 

5 The present invention relates to Session Initiation Protocol (SIP) signalling and more 
particularly to signalling handled and generated by so-called SIP exploders. 

■ 

Background to the Invention 

10 To facilitate the provision of multimedia services via the packet switched "domain", the 
3 rd Generation Partnership project (3GPP) responsible for the 3G standards has been 
developing a so-called IP Multimedia Core Network Subsystem (IMS). IMS 
communicates with the packet switched access network (e.g. GPRS) and contains all 
elements that are used to provide IP based multimedia services. For a mobile to mobile 

15 call, and assuming the mobiles belong to different networks, an IMS will be provided in 
each mobile's home network. Each IMS is connected to the GPRS network of its home 
network. The base protocol for multimedia services is the IETF Session Initiation 
Protocol (SIP) - RFC3261. SIP makes it possible for a calling party to establish a 
packet switcted session to a called party (using so-called SIP User Agents, UAs, 

20 installed in the user terminals) even though the calling party does not know the current 
IP address of the called party prior to initiating the call. SIP provides other 
functionality including the negotiation of session parameters (e.g. Quality of Service 
and codecs, with the help of the Session Description Protocol), the control of ongoing 
sessions, and the tearing down of sessions. 

25 

SIP is of course designed for use with any IP based network architecture and is not 
limited to 3G networks. In particular, SIP may be used to establish and control sessions 
over the Internet or IP LANs/WANs. 

30 The concept of the SIP "exploder" has been recently introduced in order to support 
various functionalities and services including presence services, Push to Talk over 
Cellular (PoC), Push to Show, etc. These functionalities/services have in common the 
need to distribute messages to members of pre-defined groups of receivers or to an ad- 
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hoc group of receivers. The SIP exploder is a concept borrowed from email services 
where a similar need arises, i.e. the same email messages must be distributed to 
members of pre-defined mailing lists, or to a number of destinations addresses included 
in the message itself The SIP exploder is considered in: (1) IETF: Requirements for 
5 Session Initiation Protocol (SIP) Exploder Invocation, draft-camarillo-sipping- 
exploders-01.txt; (2) IETF: Session Initiation Protocol (SIP) Exploder Invocation, draft- 
camarillo-sipping-exploders-01.txt; and (3) IETF: Session Initiation Protocol (SIP) 
Exploder Invocation, draft-camarillo-sipping-exploders-solution-OO.txt The SIP 
exploder recognises list identifiers contained within SIP Universal Resource Identifiers 

10 (URIs) and acts accordingly. For example, the URI sip:list33@somedomainxom (the 
portion "somedomain.com" identifying the home network within which the exploder is 
located) is recognised as referring to the list number 33. The SIP exploder then 
duplicates the associated message for each of the members of that list, and passes the 
messages to the Serving Call/Session Control Function (S-CSCF) for transmission to 

1 5 their destinations. 

Figure 1 illustrates a typical IMS architecture in which a Proxy CSCF (P-CSCF) 1 of 
the IMS 2 communicates with a user terminal 3 via the packet switched access network 
4. The P-CSCF 1 routes SIP signalling messages to a S-CSCF 5 which is responsible 
inter alia for maintaining data on the current location of the user terminal 3. By way of 
example, the P-CSCF may be located in a visited or home network, whilst the S-CSCF 
is located in the home network of the mobile terminal. Signalling is forwarded by the 
S-CSCF towards its destination which might include another S-CSCF in the destination 
home network and another P-CSCF in the destination visited or home network. 

A number of application servers (ASs) 6 are attached to the S-CSCF 5. These ASs 
provide various intelligent services to the IMS. The SIP exploder introduced above is 
implemented in such an AS. 

It might be the case that a list held by a SIP exploder contains URIs belonging to other 
networks. Some of these URIs may themselves correspond to lists, the members of 
which are known only to the exploders of those other networks. Figure 2 illustrates a 
scenario in which a number of IP based networks (1 to 4) exchange user and signalling 
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data, with each network comprising a SIP exploder. For simplicity, the SIP servers (P- 
CSCF and S-CSCF), access networks and other intermediate nodes have been omitted. 

For each network, a number of user terminals are shown, each of which communicates 
5 with the associated SIP exploder via the packet switched access network and the IMS: 
Exploder 1 serves a number of terminals identified as Terminals 1.1, 1.2, 1.3 and 1.4, 
Exploder 2 serves two terminals identified as Terminal 2.1 and Terminal 2.2, and so on. 
If Terminal 1.1 wants to send a message to a list hosted by Exploder 1, Exploder 1 
provides the exploder service to that terminal, i.e., sending a copy of the SIP message to 
10 each of the entries in the list. 



Figure 3 illustrates an example operation of the Exploders in which a potentially 
significant problem arises. In this example, it is assumed that Terminal 1.1 sends a SIP 
INVITE request addressed to sip: list l@exploderl. The INVITE request is denoted as 

15 step 1 in Figure 3. Exploder 1 receives the INVITE request (forwarded by the S-CSCF 
according to the application of some pre-defined rule set, e.g. forward to Exploder 1 
messages addressed to a list set) addressed to listl. As this is the first exploder in the 
path, Exploder 1 acts as the master (sometimes called "focus") of the session: this role 
is relevant in the case that a mechanism to manage "floor control" is applied (floor 

20 control can be used for example to allow only one terminal to "talk" within a session, at 
any given time). Exploder 1 sends an INVITE request to each of the entries in listl. In 
this example, listl contains four entries: the local Terminals 1.3 and 1.4, the Terminal 
2.2 located in the domain of Exploder 2, and a list2 belonging to the Exploder 2. Whilst 
the example of the SIP INVITE message is used here, this discussion applies equally to 

25 other SIP procedure such as SUBSCRIBE, MESSAGE, etc. 



A first problem with this procedure is that Exploder 1 must send two different INVITE 
requests to receivers within the same network. The INVITE requests addressed to 
Terminal 2.2 and list2@exploder2 follow the same path to the same network. This does 
30 not represent an optimal use of resources. Whilst the sending of only two different 
INVITEs may not represent a great problem, if the number of receivers in the 
destination network is high (e.g. several hundred), the required bandwidth and 
processing power may not be available. 



f 
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Considering further the procedure illustrated in Figure 3, the Exploder 2 receives the 
INVITE requests (messages 4 and 5). One request is addressed to Terminal 2.2 and is 
delivered to that Terminal as message 6. The other request is addressed to list2 in that 
5 local Exploder 2. List2 contains three entries: the local Terminal 2.1, the remote 
Terminal 3.4 in the domain of Exploder 3, and a lisO belonging to Exploder 3. 
Therefore, the Exploder 2 generates messages 7, 8 and 9. The same lack of efficient 
resource usage is again present: messages 8 and 9 are duplicated, even though they have 
to traverse the same set of nodes. Similarly, Exploder 3 receives the INVITE requests 
10 (messages 8 and 9). One request is addressed to Terminal 3.4, and delivered as message 
10. The other request is addressed to list3 at the local Exploder 3. List3 contains two 
entries: the local terminal 3.2 and the Terminal 4.2 at exploder 4. These result in 
messages 11 and 12. 

1 5 A second problem which arises as a result of the conventional procedure is the long path 
of SIP signalling that may be created between edge endpoints. For example, when 
Terminal 4.2 has to send any SIP message relating to the established session, the SIP 
message must traverse Exploder 4, Exploder 3, Exploder 2, Exploder 1 until it is finally 
distributed to Terminal 1.1. This is necessary given that each exploder is, from the SIP 

20 perspective, a UA client or server associated with a particular "leg" of the session. 

This creates a problem for real-time applications including (but not limited to) SIP. If a 
floor control mechanism is in place, and the floor control signalling follows the initial 
signalling path, Exploder 1 will be acting as the floor control manager. Terminals 
25 located "far away" in the signalling path will need to request the floor from the master 
exploder of the session (Exploder 1), and that request will take time to traverse the chain 
of exploders. As a consequence, users may not get a true real-time experience. 

A third problem with the conventional procedure is now identified with reference to 
30 Figure 4, which follows on from the procedure of Figure 3. It is assumed that list3 in 
Exploder 3 contains two entries: one pointing to the local Terminal 3.2 and the other 
pointing to a listl at Exploder 1. Exploder 3 sends the INVITE request to 
listl ©exploder 1 (message 12 in Figure 4). When Exploder 1 receives the INVITE 
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request, it is unable to determine that the INVITE has been already "exploded" and 
executed by the same list (message 1), so Exploder 1 starts the process again and sends 
a copy of the INVITE request to the four entries of listl. The signalling procedure has 
entered a loop. 

5 

It is noted that a single SIP message sent from an initiating terminal may contain 
multiple destination addresses, none of which are list addresses. Nevertheless, 
problems similar to those identified above might arise in this scenario, e.g. multiple 
messages being sent to the same destination network. 

10 

It will also be appreciated that the initiating message may be a SIP EXPLODE type 
message that carries another complete SIP message or a fragment of another SIP 
message (e.g., INVITE) together with a collection of destination addresses. The 
receiving exploder sends the encapsulated INVITE message to the various destination 
15 addresses to that user. Again, the problems identified above are likely to arise when 
using SIP EXPLODE messages in this way. 

Summary of the Invention 

It is an object of the present invention to enable interdomain traffic to be transported 
efficiently with the minimum number of messages. The number of messages exchanged 
between two domains should not depend on the number of receivers. The real-time 
characteristics of the signalling must not be dependent on the number of exploders 
involved in a multiparty session and must not be negatively affected by the presence of 
several exploders in the session. There should be a mechanism to detect and avoid 
loops resulting from the concatenation of several lists. 

According to a first aspect of the present invention there is provided a method of 
delivering a copy of a Session Initiation Protocol, SIP, message to each of a plurality of 
terminals in a multimedia communication system, the method comprising: 
receiving the message at a first SIP exploder; 

grouping destination addresses defined for the SIP message according to their 
network domains; and 
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for each group of destination addresses corresponding to a domain associated 
with a further SIP exploder, forwarding a single copy of the message to that exploder, 
the message containing all of the destination addresses of the group. 

5 Typically, the SIP exploder is an application server which receives and sends SIP 
messages via a SIP proxy server. In the example of a 3G implementation of the 
invention, this SIP proxy server maybe a Serving Call/Session Control Function (S- 
CSCF). The S-CSCF selectively forwards SIP messages to the exploder according to 
some pre-defined rule set Of course, in some implementations, the exploder may 
10 receive SIP messages directly from the SIP terminal. 

A destination address may be the address of a terminal user or an identification of a list 
of terminal users and/or other lists. 

15 In the case that a SIP message contains in the destination field a list, the members of the 
list are identified by the exploder if the list belongs to the same domain as the exploder, 
and the message is sent to each of the identified members. 

The message received at the first SIP exploder may be carried within a message of type 
20 SIP EXPLODE, in which case the destination addresses may be carried in the SIP 
EXPLODE message. 

According to a second aspect of the present invention there is provided a method of 
delivering a copy of a Session Initiation Protocol, SIP, message to each of a plurality of 

25 terminals in a multimedia communication system, the method comprising: 

receiving a SIP message at a first SIP exploder, the message having as a 
destination address an address of a list associated with a further SIP exploder; 

forwarding a copy of the message to said further SIP exploder, the message 
including the list address; 

30 at the further SIP exploder, determining whether the list contains a destination 

address associated with another exploder and, if yes, returning a SIP REFER message to 
the first exploder, the REFER message containing that destination address. 
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According to a third aspect of the present invention there is provided a method of 
delivering a SIP message to a plurality of terminals in a multimedia communication 
system which uses Session Initiation Protocol (SIP), the method comprising: 

for a given SIP message, recording at a SIP exploder the destination addresses to 
5 which that message has been sent by that exploder and comparing the destination 
addresses, associated with subsequent requests to send the same message, to the 
recorded addresses in order to avoid the sending of duplicate messages to the same 
destination addresses. 

10 In a particularly preferred embodiment of the invention, the first, second, and third 
aspects of the invention are implemented in a single system. Other embodiments may 
make use of only one or two of the aspects. 

Other aspects of the invention are set out in the appended claims. 
Brief Description of the Drawings 
Figure 1 illustrates schematically the IMS architecture; 

Figure 2 illustrates schematically a multi- network environment in which each network 
has its own SIP exploder; 

Figure 3 illustrates SIP signalling associated with setting up a multi- media session in the 
environment of Figure 2; 

Figure 4 illustrates a modified SIP signalling procedure associated with setting up a 
multi- media session in the environment of Figure 2; and 
Figure 5 illustrates further the modified SIP signalling procedure of Figure 4. 

Detailed Description of Certain Embodiments 

A new SIP message handling procedure is described here which aims to solve the 
aforementioned problems of the conventional procedures. The general principles of the 
solution are: 

1 . The first exploder in any chain is assigned as the "master" exploder of the 
session. 
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2. Subsequent exploders are assigned as "slave" exploders. 

3. The master exploder is allowed to send a copy of the SIP message to local 
resources as well as resources located in different networks (e.g., under the 
control of other exploders). 

5 4. A master exploder that is sending a copy of a SIP request to a number of 
resources sends a single copy of the SIP request per destination network, the 
request being sent to the exploder controlling the destination network and 
identifying each of the intended end users in that destination network. 

5. A slave exploder receiving a SIP request is allowed to send a copy of the SIP 
0 message only to its local resources. If, due to list expansion, the slave exploder 

needs to send a copy of the SIP request to resources not under its own control, it 
sends a SIP REFER equest back to the master exploder, the REFER request 
containing the list of external resources that must be contacted. 

6. A master exploder that receives a SIP REFER request identifying one or more 
5 destinations, creates a copy of the initial SIP request and sends it to the 

appropriate destination(s) with the same restrictions described in points 3 and 4 
above. 

7. The master exploder maintains a record of all the destination addresses to which 
it has sent messages, in order to enable it to avoid sending duplicate messages to 

0 the same user, e.g., when a user belongs to two nested lists. 



The concept of the SIP exploder has been introduced above. Lists are defined at 
exploders using various different mechanisms. For example, a user might log onto a 
web page and manage his lists interactively. Alternatively some specific protocol might 
be used. The IETF is working on a protocol, namely XCAP (XML Configuration 
Access Protocol), that provides the functionality to configure lists. 3GPP has defined an 
interface between Application Servers (the exploder is an Application Server) and the 
IMS terminals. This interface is named the Ut interface, and the protocol is referred to 
as XCAP. Yet another alternative is for network administrators to manage lists. 



Figure 5 illustrates the proposed procedure, again using the example of the SIP INVITE 
message. The message is assumed to have the same properties as the message used in 
the example described with reference to Figures 2 and 3. Terminal 1.1 sends the SIP 
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INVITE request addressed to 1 istl ©exploder 1. As Exploderl is the first exploder in the 
chain, it adopts the role of the master exploder for the session, and signals its role in the 
SEP messages that it subsequently sends. This may be achieved using the existing 
IsFocus parameter contained in the SIP Contact header. When a User Agent inserts an 
5 "isfocus" parameter in that header, it is signalling that it is acting as a focus for a 
centralized conference system. The "isfocus" parameter is defined in draft- ietfsip- 
callee-caps-02.txt. 

Exploder 1 receives the INVITE request (message 1 in Figure 5) and evaluates the 
10 contents of list 1. Listl contains entries for two local terminals, so Exploder 1 sends an 
INVITE request to each of these terminals (messages 2 and 3). Listl also contains two 
entries that belong to the same administrative domain, i.e. "exploder2". These two 
entries are terminal2.2@exploder 2 and Hst2@exploder2. Exploder 1 sends a single 
INVITE request (message 4) addressed to both terminal2.2@exploder2 and 
1 5 list2@exploder2. 

Exploder 2 receives the INVITE request (message 4) addressed to both the local 
terminal 2.2 and list2. It determines from message 4 that it is not the master exploder of 
the session, so it adopts the role of the slave exploder of the session. Exploder 2 then 

20 creates an INVITE request and sends it to Terminal 2.2 (message 5). Then Exploder 2 
evaluates list2 and finds three entries: one of these is local (Terminal 2.1), the other two 
are not (Terminal3.4@exploder 3 and Hst3@exploder3). As Exploder 2 has adopted the 
role of the slave exploder of the session, it only creates a copy of the INVITE request 
for the local Terminal: it does not create copies of the INVITE request to entities that 

25 are located outside its own control. Rather, it sends a SIP REFER request [IETF: The 
Session Initiation Protocol (SIP) Refer Method, RFC 3515] back to Exploder 1 
(message 7 in Figure 5). The REFER request contains the contents of the list2 that are 
not local to Exploder 2, i.e. Terminal3.4@exploder3 and list3@exploder3. 

30 Exploder 1 receives the REFER request and collects the addresses contained in the 
message into groups according to their local networks. In this example, both addresses 
in the REFER request (message 7) are part of the network controlled by Exploder 3. 
Therefore, Exploder 1 creates a new INVITE request addressed to 
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Terminal3.4@exploder3 and list3@exploder3 and it sends it to Exploder 3 (message 8 
in Figure 5). The INVITE request again contains an indication that Exploder 1 is acting 
as the master exploder of the session. 

5 Exploder 3 receives the INVITE request (message 8) and it sends a copy to its local 
Terminal 3.4 (message 9). It then evaluates the other destination, namely list3. List3 
contains two entries, one local (Terminal 3.2), so Exploder 3 sends a copy of the 
INVITE request to Terminal 3.2 (message 10). The other entry in list3 points to 
Terminal4.2@exploder 4. As Exploder 3 is not the master exploder of the session, 
10 Exploder 3 does not send an INVITE to any resource bcated outside its own domain. 
Instead, Exploder 3 creates a REFER request (message 11 in Figure 5) with 
Terminal4.2@exploder4 as the final destination and sends it back to Exploder 1. 

Exploder 1 receives the REFER request (message 1 1 in Figure 5) and creates a copy of 
15 the INVITE request addressed to Terminal4.2@exploder4 (message 12). When 
Exploder 4 receives the INVITE request, it explodes only to its local resources, in this 
case Terminal4.2 (message 13). 

Although in this example the originating SIP INVITE message contains only a single 
20 destination address (i.e. listl@exploderl) , the message may contain multiple destination 
addresses. This option is used, for example, in so-called Push-to- Talk Over Cellular 
(POC) services. 

In a variation of the procedure described above, SIP messages destined for multiple 
25 users may be carried within a SIP EXPLODE message type. The destination addresses 
are carried in the EXPLODE message. A SCSCF node will automatically forward 
EXPLODE type messages to the attached exploder. 

The solution presented here is worthy because the signalling path established is of a star 
30 configuration, with the master exploder at the centre of the star and the slave exploders 
around the periphery, rather than a chain. All subsequent signalling between any two 
terminals will need to traverse at most two exploders, independent of the total number 
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of exploders in the session. The real-time characteristics of a session are not critically 
dependent upon the number of exploders in the session. 

Figure 5 illustrates how the same SIP signalling procedure also solves the loop problem 
5 identified above. Considering Exploder 3, when it receives an INVITE request 
(message 8) addressed, among others, to list3@exploder3, it will not explode to 
resources located beyond its own control. Therefore, it will send a REFER request back 
to Exploder 1 (message 11), the REFER request indicating that listl@exp!oderl must 
be contacted. 

10 

Exploder 1 is aware that it is acting as the master exploder for the session. It maintains 
a list of all the resources currently involved, directly (terminals and lists) or indirectly 
(resources in lists). Therefore, Exploder 1 is aware that listl@exploderl has been 
already been expanded and each entry has been contacted and added to the session. 
15 Therefore, there is no need to expand list 1 ©exploder 1 again. The session setup 
procedure is considered to be complete, and no more actions are taken at Exploder 1 
during this phase. 



